Migrating a High-Volume VoIP Database With Zero Downtime
A high-volume cloud phone provider needed to modernize the database at the core of its VoIP network without interrupting service. We handled the full zero-downtime database migration, moving 2 TB of live data across database engines while both versions stayed in sync. The work drew on the same open-source VoIP infrastructure expertise we bring to every telephony project.
The Challenge
A cloud phone provider running a high volume of calls came to us to modernize the database at the heart of its network. That database was the workhorse of the whole operation, under constant load, and it was running on an older version with storage engines the vendor had deprecated. Moving to the newer version was not optional, but the provider could not afford to lose data or drop calls to do it. Three things made this hard.
Move 2 TB of live data without losing any of it
The database held more than 2 TB of business-critical data, roughly 500 million documents. Every one of them had to move from the old storage engine to a new one with zero data loss and zero corruption. At that scale, even a tiny error rate means thousands of broken records.
Keep the phones working the entire time
The provider handles calls around the clock, so there was no maintenance window to take the system offline. The migration had to run with no downtime. That meant the old and new versions of the database had to run side by side and stay in sync in both directions, so either one could serve live traffic until the final cutover.
Survive failures partway through
A migration this large takes time, and things break along the way. The replication had to be resilient. If it failed, it had to pick up again from the exact point it stopped rather than starting the whole 2 TB transfer over from the beginning.
The Solution
We treated the migration as an event-driven data streaming problem rather than a one-time copy. Instead of moving the data in a single bulk transfer, we streamed every change from one database version to the other, continuously and in both directions, until the two were identical and the provider could switch over safely.
Replay every change, both directions
The core idea was simple. We read every create, update, and delete operation from the older database's operation log (the oplog) and replayed it on the newer version, and did the same in reverse. Because the underlying NoSQL database abstracts away a lot of the storage detail, this approach sidestepped the incompatibilities between the old and new storage engines instead of fighting them.
An event-driven pipeline that survives failure
To make the replication resilient, we built a streaming pipeline from three parts. A Debezium connector reads the change logs from the source database's oplog and pushes them into Kafka. Kafka queues those changes in order. A Python consumer script then reads them from Kafka and applies them to the destination database. Because Kafka tracks what has been processed, a failure anywhere in the chain just resumes from the last handled change rather than restarting the whole migration.
Prove nothing was lost
Moving the data is only half the job. Proving it arrived intact is the other half. We wrote verification scripts that pulled samples from both the old and new databases and checked them against each other for integrity, so the provider had evidence that all 500 million documents matched before and after the move.
Land it on modern infrastructure
Alongside the version upgrade, the network moved to AWS, so the provider came out of the project on current database technology and cloud infrastructure at the same time, without a second disruptive migration later.
Highlights
2 TB
Migrated with zero data loss or corruption
500M Documents
Replicated across database engines
Zero Downtime
No interruption to customer calls
Ready to scale your VoIP infrastructure?
Let our experts architect a high-performance, resilient communication platform tailored to your specific requirements.
Get Started Today